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Abstract — This paper presents a big-step operational seman- 
tics for distributed lazy evaluation. Our semantics is an extension 
to the famous heap-based semantics of Launchbury for lazy 
evaluation. The high level of abstraction in our semantics helps 
us to easily prove different properties that are of interest to task 
distribution. Most importantly, we give criteria which establish a 
notion of bisimilarity between heaps. We also prove the validity 
of an induction principle that is used for proving observational 
equivalence between programs written in our system. Addition- 
ally, we explain how the component-based nature of a formerly 
presented material for mechanisation of Programming Languages 
(PLs) facilitates experimentation with the semantics of this paper. 

Keywords — Big-Step Operational Semantics, Distributed Pro- 
gramming, Lazy Evaluation, Language Mechanisation 

I. Introduction 

Laziness avoids variable evaluation so long as the value 
of that variable is not needed elsewhere in the expressions of 
interest. Moreover, as formalised first in [ 1 6], laziness prohibits 
more than one evaluation for every variable through the 
intuitive concept of heaps. The motivation for this indirection 
is saving unneeded evaluations. There are various reasons, 
however, that the programmer may choose to enforce strictness 
(e.g., controlling execution flow and space or time efficiency). 
To accommodate that, works such as [24], [5] extend lazy 
evaluation with selective strictness but for sequential programs. 

With the growth of multicore systems, different research 
threads have tried to study non-sequential ways to enforce 
strictness. Examples include employing parallelism [9], [2] 
or distribution [11], [10]. These works, however, all offer 
small-step semantics that - although much more natural for 
describing interleaved computations - is not as easy as big- 
step systems to reason about. More specifically, proving that 
programs operate similarly is known to be particularly difficult 
in small-step semantics. (See [11] for some denotational ap- 
proaches in proving program equivalence for distributed lazy 
evaluation.) 

Proving observational equivalence in the lazy evaluation 
campaign was first studied in [5]. These proofs were all for 
selective strictness and for a flavour of laziness that unfor- 
tunately suffers from expressiveness restrictions. Later on, it 
was shown in [6] that the same results hold even when those 
restrictions are removed. The most notable technique used in 
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the latter works for proving observational equivalence is a 
new induction principle called Induction on the Number of 
Manipulated Bindings (INMB). 

In this work, we provide a new big-step operational se- 
mantics for distributed lazy evaluation (Definition 6). Our 
semantics, although not the first big-step system for this 
purpose, is remarkably simpler than its single predecessor (i.e., 
[21]). Thanks to the simplicity of our semantics, we can prove 
various results about it that are of interest to task distribution: 
We prove INMB (Theorem 2) that, in return, is used in 
proving bisimilarity between the heaps used over an evaluation 
(Theorem 7). We also prove two observational equivalences 
that dismiss the need for performing certain parts of derivations 
(Corollary 1 and 2). Likewise, we prove that the order in which 
certain heaps are merged does not matter (Corollary 4). The 
two latter results can be viewed as optimisation legislations. 
Finally, we show that - despite addressing distribution - our 
semantics enjoys a notion of determinism (Theorem 1). The 
proofs we omit here can all be found in [7]. 

A plus about our semantics is that it is mechanised. Mecha- 
nisation of a language is implementing it for the experimental 
study of its characteristics and conduct. One interacts with 
the mechanisation to discover otherwise inapparent facts or 
flaws in action. We demo our system's mechanisation to 
explain how the particular mechanisation approach we used 
caters distribution at a high level of abstraction. We specifically 
present our distribution rule's mechanisation for its pivotal role. 

This paper is organised as follows: We start by presenting 
our syntax and semantics in Section II. Some properties of 
our system are explored in Section III. Section IV focuses on 
heap bisimilarity and its importance for task distribution. Then, 
in Section V, we discuss the mechanisation of our system. A 
review on the related work is provided in Section VI. Finally, 
in Section VII, we conclude and discuss future work. 

II. Syntax and Semantics 

This section presents the syntax and semantics of our 
system. We also provide a few related definitions and notations 
that we will refer to later. 

Definition 1: Fix a countably infinite set of variable sym- 
bols, x, y, z, . . . and x%, X2, ■ ■ ■ will range over variable sym- 



bols. Define the DLE 1 expressions by 
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let{a*=ei}? =1 


in Xx.e 


(71 > 0) 


Val 


let{a;i=ei}™ =1 
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(e £ Val) 


Let 



(T,Xi H> ei)\ =1 = (T,X! n- ei), and 

(r, Xi i ^ e i)"=i = ((r, i— > ej)™ =1 , x r 



where the rightmost column presents the syntactic category at 
each row. e, e', e\, . . .will range over expressions (Exp), v, v', 
V\, ...will range over values (Val). The name Srp ("sharp") 
denotes strict function application. (More on this later.) We will 
use the names of syntactic categories as if they were predicates 
that indicate membership. For example, Val(e) means e E Val. 

We will drop the let-bindings in let {x;=ei}™ =1 in Xx.e 
when 7i = and simply write Xx.e. Adding extra let-bindings 
to a value again results in a value. We inherit Launchbury's 
[16] standard restriction in that functions can only be applied to 
variables. As stated in [16], this does not reduce expressiveness 
because we also have let. The same argument holds for strict 
application, i.e., e#x. 

We quotient syntax up to a-equivalence of A- and let-bound 
variables. For example, Xx.x = Xy.y. This design dismisses 
the need for local freshness check in [22]. 

Call let {xi—ei}f =1 in Xx.e let-surrounded abstractions. 

In considering let-surrounded abstractions values, we follow 
Ariola and Felleisen [1]. Hereafter, unless stated otherwise, 
for \et{xi=ei}f =1 in Xx.e we assume that n > 1. 

Definition 2: Define fu(e) the free variables of e by: 

fv(x) = {x} fv(Xx.e) = fv(e) \ {x} 
fv(ex) =fv(e) U {x} fv( e # x ) = M e ) u i x ) 

Mlet^eiKUine) = (M e ) U|J?=i/«fe)) \ 

Remark 1: We assume that all bound variables are dis- 
tinct. As a result, we do not need to distinguish between 
let {yi = ex,y 2 = e 2 } in Xx.e and let {j/i = ei} in (let {y 2 = 
e 2 } in Xx.e). We choose the former expression as a syntactic 
shorthand for the latter. We handle mutual recursion like 
Launchbury ([16, §3.2.1]). The implication is that y\ and 7/2 
here can well be mutually recursive. 

Notation 1: Write e[y/x] for the usual capture-avoiding 
substitution of x by y in e. For example, (Xy.x)[y/x] — Xy'.y, 
when x, y, and y' are distinct variables. Moreover, write 
(v)~ x [y/_] for (\et{xi=ei}f =1 \ne)[y/x] where the value v 
is let {xi=ei}2 = i in Xx.e. In words, by (v)~ x [y/_], we denote 
the result of "removing tj's outmost A and replacing all the 
occurrences of the argument bound to that A - i.e., x in this 
case - by the variable y." 

Definition 3: For a partial function /, define 
dom(f) — {x I f(x) defined}. Call a partial function 
r mapping variable symbols to expressions and such that 
dom(Y) is finite, a heap. T, A, 6, and S will range over 
heaps. When x $ dom(T), define (Y, x i-> e) such that 

• (r,x i-> e)(a;) = e, and 

• (r,x4 e)(y) = T(y) when y ^ x. 
Besides, 

'DLE = Distributed Lazy Evaluation 



Definition 4: For x E dom(T), define r[x H> e] as: 

• T[x h-> e](x) = e, and 

• T[a; H> e](y) = T(y) when (y ^ x). 
Furthermore, 

• r[iCi H- ei]\ =1 = T[x! ex], and 

• T[xi 1— > e^ =1 = (Tlx, 1— > e^-^Xn ^ e„]. 



We overload the notation T[Xi 
be T itself. 



for when 71 = to 



Remark 2: Note the difference between the notations 
T[x H> e] and (T,x i-> e): The former is well-formed when 
x E dom(T). To the contrary, the latter is well-formed when 

x ^ dom(T). The former updates an existing binding whereas 
the latter augments the heap with a new one. 

Definition 5: Let Ti and T 2 be two heaps that bind the 
exact same variables, i.e., dom(Ti) = rfor?i(r2). Define Y\ tx 
T 2 as Txixi 1 ^ u 4 ]f =1 where {^}? =1 = {x | Val(r 2 (x)) A 
-.Val(r x (x))} and tj 4 = T 2 {xi) for 1 < i < n. 

For the appropriate Y\ and T 2 , the intuition is that Y\ X T 2 
is Ti itself some bindings of which are updated with values 
from r 2 that preserve semantics. This update is particularly 
useful when, over the same derivation, T 2 is done with the 
evaluation of certain variables that are still bound to non-value 
expressions in Ti. Note that not for every T 2 will Y\ txi T 2 
have the same semantics as T\. See Example 1 for more. 

Definition 6: Define the DLE big-step operational seman- 
tics r : e JJ. A : v as shown in Fig. 1 where: 

• In (var x ), by Definition 3, we assume x ^ dom(Y). 

• In (let), l Xi fresh' means X{ dom(Y) and £ 
fv(Y(x)) for x E domiY), and similarly for A. 2 

Intuitively, r : e JJ. A : v is: "Trying to evaluate expression 
e in heap Y will result in value v whilst the (probably 
manipulated) bindings are stored in A". 

Remark 3: In line with Remark 1, for any expression 
e = let {xi=ei}f =1 in e' to be evaluated, all occurrences of 
Xi's in e refer to the local let-bound x^'s. Especially, so 
are the free occurrences of Xj's, which are therefore needed 
to be distinguished from free variables of e. A particularly 
interesting impact this has in our system is how we define 
free variables for let expressions (Definition 2). 

Notation 2: A derivation is the labelled tree — labelled 
with terms, heaps, and derivation rules from Definition 6 — 
that justifies a reduction r : e JJ. A : v. IT, IIi, EE', IL, . . . will 
range over derivations. Write T : e JJ. A : v* as shorthand 
for 'T : e JJ. A : v is derivable". Write T : e J|n A : v' 
as shorthand for "II is a derivation of Y : e JJ- A : v". "_" 
will represent the wildcard in our notation, so that, by T : 
e JJ. A : _', we are clarifying our lack of interest in the final 
value obtained after evaluating e in Y. Write T : e JJ-n' for 
T : e 4J-n _ : _'■ For a derivation Y : _ JJ. A : _, call Y and A 
the original and final heaps, respectively. 

2 Consistent with [16] and subsequent work, we allow the possibility that 

x i £ t v { e j) or x i £ f v ( e j) f° r 1 ^ i>j 5~ n - 



( va n r:e ^ A: ^ , T:e^Q:v e 9 : (v e y x [x/_] JJ A : v 

r 11 r 1 ' (var x ) (app) 

r:u ^ r:w (T,x^e):x^(A,x^v):v T:ex^A:v K 1 

r:eJJ,Gi:u e T : x JJ. 9 2 : _ 9i CX 9 2 : (v e )~ A [z/J JJ. A : w 

r : e#a; 4J- A : x; # 
(r, :E,i->-ei)f =1 :e JJ. (A, iii->e')'' =1 :« when fresh, 1 < i < n 

(let) 

T : let {^=ei}f =1 in e JJ, A : let {x^e'^i in « 

Fig. 1. Our Operational Semantics 



All our rules but (#) are those of [6] except that we 
drop their (seq) rule for selective strictness. Note a particular 
consequence of our choice for let-surrounded abstractions to 
be values: In our (let) rule, we can put special care in 
place for 'garbage-collecting' the let-bindings which are of 
no relevance to heap A (i.e., those of Xi's). J The rule for 
let in [16], [24] does not garbage collect. For them, heaps 
are left with extra bindings after evaluation of let-expressions. 
The semantics in [16], [24] allows variables to escape their 
scope during evaluation, which is forbidden in our semantics. 
For example, in [16], evaluation of let x = Xy.y in Xz.(xz) 
finishes by adding x H> Xy.y to the original heap; this could 
then 'accidentally' bind x occurring elsewhere in the next 
expressions to evaluate. Launchbury is well aware of this 
issue and comments on it [16, §3.1]. To avoid 'accidental 
name-clash' in evaluations in his system, he imposes a pre- 
evaluation normalisation for expressions which renames all the 
variables already bound in heap. This normalisation is fine, if 
we just want to evaluate a single expression in a single heap. 
However, as discussed in detail in [5], [6], for reasoning about 
the evaluation of classes of programs and proving operational 
equivalences between them, a garbage-collecting rule for let 
is better. 

Remark 4: Our rules are applicable based on a best- 
fit strategy: The final rule in T : let {xi=ei}JL 1 in v JJ. 
r : let {xi—ei}" =1 in v is always (val) as opposed to 
(let). In retrospect, in T : let {xi=ei}™ =l in e JJ. A : 
v, the final rule is (let) when ^Val(e). Here is an 
interesting related observation for expressions such as 
e = let x = (let {} in Xy.y) in (let {} in Xt.t). Note first 
that, according to our convention explained in Remark 1, we 
identify e and let x = (let {} in Xy.y) in Xt.t. Therefore, 
the syntactic category of e is Val rather than Let. Clearly then 
(val) is the last rule applied in the evaluation of e. In other 
words, inclusion of (val) and (let) together in our operational 
semantics does not make it non-deterministic. 

The intuition behind our (jf) rule is that evaluation of e 
and x can happen independently and perhaps simultaneously. 
Hence, the implementation is free to assign each evaluation to 
a separate thread/processor. This freedom is the key to our task 
distribution. One reason why, out of the rules in Figure 1, we 
only present the mechanisation of (#=) is this pivotal role of it. 
(This is done in Section V-A.) In words, (#) reads as follows: 
"Evaluate both e and x in the original heap; keep the first 
resulting value but discard the second; evaluate the suitably 



3 This particular use of the term 'garbage-collection' is due to Launchbury 
[16, §6.2]. 



substituted expression in a heap which is suitably produced out 
of the resulting heaps of the two former steps; return both the 
resulting heap and expression intact." Refer back to Notation 1 
for more on (v e )~ x [x/_\. 

Example 1: Let T\ = {x\ 1— > Xt.t,X2 i-> (Xx.x) x\} and 
T 2 = {^1 >-> Xt.t,X2 n- Xx.Xy.x}. Then, by Definition 5, 
r 3 = Ti cxi r 2 = {xi 1 y Xt.t,X2 1— > Xx.Xy.x}. Note, 
however, that Ti and T 2 do not have the same semantics 
because Ti : x 2 JJ- _ : Xt.t but T 2 : x 2 4J- _ : Xx.Xy.x. In other 
words, replacing a; 2 's binding over the process of building T 3 
does not preserve the semantics of T±. Corollary 4 describes 
a situation when tx does preserve semantics. □ 

III. Properties 

This section provides half a dozen important properties of 
DLE. We start with Section III-A to discuss properties that, 
although fundamental, are still interesting on their own. We 
prove two observational equivalences using these properties. 
Then, in Section III-B, we present Inmb along with the major 
results used to prove its validity for our system. Inmb is the 
technique we use to prove Theorem 6. 

A. Fundamental Properties and Equivalences 

The most important result in this section is Theorem 1 that 
plays a key role in proving properties of DLE. Corollaries 1 
and 2 demonstrate two immediate instances where the role of 
Theorem 1 is canonical. 

Lemma 1: Suppose that T : _ 4J. A : _. Then, dom(T) = 
dom(A). Besides, Vx € dom{T). Val(r(a;)) => Val(A(a;)). 

Proof: Rule-based induction. ■ 

Lemma 2: 9 2 (x) € Val implies (9i cxi Q 2 )(x) £ Val. 

Lemma 3 (Idempotence o/cxi); T IX T = T. 

Theorem 1 (Determinism): Let T : e JJ. Ai : v\ and T : 
e JJ. A2 : t>2- Then, Ai = A 2 and v\ = u 2 . 

Proof: Rule-based induction. ■ 

Definition 7 (Strict Equivalence [5], [6]): Define e\ ~ s 
e 2 by: 

Vr, v, A. (r : ex JJ- A : v) o (T : e 2 JJ. A : v). 

Intuitively, e\ ~ s e 2 when, given the same original heap, 
ei and e 2 always compute the same final value and final heap. 

Corollary 1 (Strictness Dismissal): x#x ~ s x x. 



Proof: Suppose that T : x x JJ. A : v. The derivation takes 
the following form: 



r:n|A:i) 



(app). 



We use III and 1I2 to build a derivation for V : x#x JJ. A : v 
as follows: 



T : x JJ-m © : v x T : x JJ-m 9 : _ 

0x0: {v x )' x [x/_} %i 2 A:w 

T : JJ. A : i> 



(#)• 



Note that, according to Lemma 3, XI 9 = 0. Furthermore, 
due to Determinism (Theorem 1), if T : x#x JJ. A' : v', 
then A — A' and v = v' . The proof is similar for the other 
direction. The result follows by Definition 7. ■ 

In words, Corollary 1 dismisses the need for spawning a 
new process for evaluating strict self-applications. This goes 
well with the intuition that, in self-application, evaluation 
of the function has already addressed the evaluation of the 
argument too. 

Corollary 2: (e#x)#a; ~ s (e#x) x. 

Proof: Suppose that T : (e#x)#x JJ- A : v. The derivation 
takes the form: 

T : e#z J| ni 9' : v' T : x 4J. 9 2 : _ 

e'M9 2 : 0')" A b/J ^n 2 A : v 



T : {e#x)#x JJ. A : v 



(#) 



where ITi is 



T : e JJ, 6i : v e V : x JJ. 2 : _ 

©i X0 2 : («e)- A [a;/_] 4©' : »' 



T : e#a; JJ. 0' : v' 

Note now that 
Vy G dom(r).Val(0 2 (y)) Lemma 2 

Val((0i XI 2 )(y)) => Lemma 1 

Val(0'(y)) 

fiy. Val(0 2 (t/)) A -Val(0'(y)) =*> 0' X 2 = 0'. 
We build T : (e#x) x JJ. A : v using ITi and n 2 : 

T : e#x V 0' : v' 0' : Kr^/J JJ-n 2 A : v 



(#)• 



T : (e#x) x JJ. A : w 
The result follows by Determinism (Theorem 1). 



(app). 



Again, Corollary 2 dismisses the need for spawning a new 
process for the task that is already addressed. The important 
observation is that we easily prove such intuitive equivalences 
because of the simplicity in our semantics. In particular, in our 
proofs, we are not burdened with the bookkeeping information 
for interprocess communication. This would have not been 
the case if we wanted to try the same proofs under the 
system of Sanchez-Gil et al. [ ]. See the closing paragraph 
of Section VI-A for a related discussion. 



B. The Induction Principle 

In this section we present a formulation of Inmb and give 
a summary of what it takes to prove it for the operational 
semantics of Definition 6. We begin by a necessary definition: 

Definition 8: Suppose T : e J|n A : v. Define diff(H) by: 

dijf(tt) = {xe dom{T) \ T(x) ^ A(x)}. 

Intuitively, diff(H) is those variables bindings of which are 
manipulated over IT. We now get to a formulation of Inmb 

[p(n) ; diff(n) = 0] 

A 

[Vfc.(P(n) ; ||^(n)|| =k)=> 

(P(IL);\\diff(Il)\\=k + l)} 



Vn. P(H);\\diff(n)\\ 



(Inmb). 



In words, (Inmb) states that: "P(IT) holds if: (1) P(U) holds 
when no binding gets manipulated over derivation II. And, (2) 
validity of -P(II) when there are k manipulated bindings in 
derivation II implies validity of P(II) when there are k + 1 
manipulated bindings." 

Inmb has a deceivingly simple statement. The proof of 
its validity is, however, by no means trivial. The rest of this 
section retraces the major steps. 

Theorem 2: Inmb is valid for the operational semantics in 
Definition 6. 

Proof: Using Theorems 3, 4 and 5. ■ 

In order to state the theorems used in the proof of Theo- 
rem 2, we need to lay down some pieces of terminology. 

Definition 9: Suppose r : e JJ. n A : v. Write V(I\) for 
the set of x 6 dom(T) such that II contains an instance of 
(var x ). 

Definition 10: Call x atomic in T when there exist A^,, 
v x , and EL such that T : x JJ-n x A^ : v x and diff(H x ) = {x}. 
Write atomic(T) for the set of atomic variable symbols in T. 

The intuition is that a variable is atomic when "its evalu- 
ation only manipulates the binding of the variable itself." We 
next extend Definition 4 to full derivations: 

Definition 11: Suppose T : e 4J-n A : v and suppose II 
contains no instance of (var x ). Then, for any e', define H[x M- 
e'] to be the labelled tree obtained from IT by replacing every 
heap appearing in IT with 0[a; H> e'] if x £ dom(Q); 
otherwise, we leave unchanged. 

We will prefer the following slightly more succinct char- 
acterisation of atomicity: 

Lemma 4: x £ atomic(T) if and only if there exist v x and 
U x such that T : x JJ.n x T[a; H> v x ] : v x and diff(H x ) = {x}. 

Here is our last ingredient for Theorems 3, 4 and 5: 

Definition 12: Suppose T : e JJ-n A : v such that x £ 
^(IT). Suppose also that x € atomiciT), so that in particular 
r : x JJ-n x A x : v x for some IT.,., A^, and v x . 

We define a labelled tree IT ([a; 1— > v x } by inductively 
transforming IT based on its final rule. For each subcase, 



• when x ^ dom(T) one V^II) \ atomic(T), define 

n([x i ^ v x }) = n. (1) 

• when x ^ V(II), define 

U([x^v x ]) =H[x^v x ]. (2) 
The subcases where x £ atomic(T)0 V(U) are defined below. 

• (var x ). II takes the form 



r' : e x JJ, T' : v x 



(r', x n- ex) : x 4 (r', x ^ v x ) : v x 
Define n([x h- !► w x ]) to be 

(val) 



T' : ^ J| T' : 



(var x ). 



(var x ). 



(r', x H> u x ) : x JJ. (r', a; ^ : w K 

(let) and (var y ) for y other than x. IT takes the 
form 

: n ' 

r' : e' i A' : v' 

(r) 

T : eJJ. A : v 

where (r) g {(var y ), (let)}. Define Il([x M> v x ]) to 
be 

: IL'Gx i — ^ 



T'[x H> w x ] : e' JJ A' [x i-> u x ] : w' 



r[x i— > u x ] : e JJ A[x h- > ?; x ] : w 

The transformation for (app) and (#=) takes the same bottom- 
up fashion of the latter case. Note that (val) can never be the 
final rule when x <E atomic(T) n K(II) because V(II) = in 
this case. Hence, the recipe for this case is (2) where II([x H> 
v x ]/ = IT[x i — y Vx\ = n especially. (See Definition 4.) □ 

Theorems 3 and 4, respectively, explain how to remove and 
restore an atomic variable from a derivation to obtain another 
(valid) derivation. 

Theorem 3: Suppose T : e JJn A : v and x g ^(n). 
Suppose x € afo?TOc(r); so in particular T : x JJn T 
r[x H> fa;] : for some v x . Then, A(x) = v x and 
r[x H> : e Jln^M-i^]) ^ : v - Furthermore, 

diff{n{ x ^v x ])) = diff(ii)\{x} 
v(n([x^v x })uv(u x ) = v(u) 
xe V(U<lx^v x }). 

Theorem 4: Suppose x £ atomic (T); so, in particular, 
r : x -||n x r [x i — y v. x ] : v x for some v. x , and II.,, such that 
diff(H x ) = {x}. Suppose also that T([x >-> v x } : e JJ-n' A : v 
and x € V(II'). Then, T : e J| n A : v for a n such that 
II([x i y Vx }) = IT and x € V(Il). 

Theorem 5 proves that any derivation either manipulates 
no bindings, or, of the manipulated bindings at least one binds 
an atomic variable in the original heap. (See Notation 2 for 
the definition of original heap.) 

Theorem 5: Suppose V : e JJ-n A : v. Then exactly one of 
the following possibilities holds: diff(H) = 0; or there exists 
an x £ diffili) such that x <E atomic(T). 



IV. Heap Bisimilarity 

The results in this section give criteria for when using one 
heap instead of the other does not risk correctness. Bisimilar 
heaps can be passed around in place of each other because 
they are guaranteed to always produce the same results. We 
begin by introducing our transition system. Then, we define a 
relation on the set of heaps that we later show is a bisimulation 
for our transition system: 

Definition 13: Let H be the set of all heaps. Define ^4 



such that 



T2) when: 



for the transition system 2?^ = (H, Exp x Val, -^4 

T 1 ^ T 2 when T 1 : e T 2 : v. 
Definition 14: Call Ti and T 2 analogous (Ti s= 

Ve,u. ((ri:eJJ._:v)4»(T a :e -!)._:«) 



In words, two heaps are called analogous when they 
"always evaluate the same expression to the same value." Note 
that this definition is indeed also taking irreducibility into 
consideration: If the evaluation of an expression e (such as 
let z = Ax.(xx) in zz) in one of the two analogous heaps 
does not terminate, e's evaluation should not terminate in the 
other heap either. Likewise, if an expression's evaluation halts 
abruptly in one heap - say, due to unavailability of a requested 
binding - the same evaluation should halt abruptly for the other 
analogous heap too. 

Lemma 5: pa is an equivalence relation (reflexive, transi- 
tive, symmetric). 

Theorem 6: Suppose that T : _ JJ. A : _. Then, T A. 

Proof: Using Inmb. ■ 

Corollary 3: Let V : _ JJ. Ai : _ and T : _ JJ. A 2 : _. Then, 
Ai«Aj. 

Proof: Using Theorem 6 and Lemma 5. ■ 

Corollary 4 (Symmetry o/txij; When r : e\ JJ. Ai : _ and 
r : e 2 JJ- A 2 : _ for some arbitrary e\ and e 2 , Ai M A 2 = 
A 2 ix Ai. 

Proof: Note first that, by Lemma 1, dom(Ai) = 
dom(T) — dom(A 2 ) and both Ai X A 2 and A 2 IX Ai 
are well-formed. Suppose that T : e\ JJnj Ai : _ and 
T : e 2 JJn 2 A 2 : _. We distinguish between four cases: 

• x £ diffiJlt) U diff(U 2 ) Then, (A 1 m A 2 )(x) = 
T(x) = (A 2 m Ai)(x). 

• x £ diffillx) \ diff(U 2 ) Then, (A 1 m A 2 )(x) = 
Ai(x) = (A 2 tx Ai)(x). 

. x £ diff(R 2 ) \ diff{n x ) Then, (A 2 m A 1 ){x) = 
A 2 (x) = (Ai tx A 2 )(x). 

• x £ dijf(Ili) n dijJ(U 2 ) Let A x (x) = v lx and 
A 2 (x) = v 2x . By Corollary 3, A x sa A 2 . That is, 
by Definition 14, v\ x — v 2x . 

The result follows. ■ 

Corollary 4 legislates changing the bowtie (>d) order of 
one heap into another. One might want to do this for various 



reasons, including: proximity of the bindings that are subject 
to update upon the bowtie, their locality issues, and the 
channelling costs involved. 

Lemma 6: s» is a bisimulation for 

Proof: Fix Ti and T 2 s.t. Ti « T 2 and I?i ^ Ar for 
some heap Ai. If we show that there exists a heap A2 such 

that T 2 — A2 and Ai ss A2, the result follows by symmetry. 

By construction (Definition 13), Tx Ai means Ti : 
e JJ-ri! Aj : v for some Hi. Given that Fx w T 2 , by 
construction (Definition 14), it follows that there exists a heap 
A2 such that r 2 : e J| A2 : v. By Theorem 6, T\ s» Ai and 
F 2 « A 2 . The result follows by transitivity of ss (Lemma 5). 

■ 

Theorem 7: w is the bisimilarity for ,3^. 

Proof: Using Lemma 6 and Definition 13. ■ 

Due to their number of bindings, size of expressions 
they bind, and many other reasons, passing heaps around 
can become expensive - especially, when remote inter- 
communication is entailed. A special occasion where that 
might be needed is when updating a local heap with bindings 
of another. Theorem 7 dismisses that need when the heaps 
involved are known to be analogous. 

V. Mechanisation 

This section first gives an overview about the mechanisa- 
tion approach that we used for this paper. We next report the 
benefits we gained from the mechanisation exercise. At last, we 
present our new mechanisation component that we developed 
to use together with the existing ones that we reused. 

Figure 2 is a snapshot of a Scala session that shows the suc- 
cessful reduction of T : (\zi.\z2.Zi)#xi, where V (denoted 
in the code by G) is {xi n- Xx.x,x 2 n- X\ y}. Generally, 
in this framework, g < : : > e outputs the derivation V : e JJ., 
when derivable; it produces an error message otherwise. For 
example, attempting to evaluate x$ in the above V will throw 
the following exception: 

Evaluating unbound variable x3 in heap G 

In our former work [ ] we promoted component- 
based mechanisation (CBM) of PLs. CBM is the familiar 
Component-Based Software Engineering (CBSE) applied in 
the field of PL mechanisation. The idea leads to a separation 
of concerns between the PL developers, mechanisation compo- 
nent vendors, and Language Definitional Frameworks (LDFs): 
An LDF provides the necessary environment and standards 
for the development of the components as well as PL imple- 
mentation using them 4 ; the component vendors enjoy the LDF 
environment to deliver components; and, the PL implementers 
mix and match the available PL components to get their desired 
PL mechanised. Such components need to enjoy a plug-and- 
play nature: That is, the PL implementer simply picks their 
desirable PL components from an available repository; and, as 
soon as they (correctly) plug the chosen components together, 
they are ready to kick-off the experimentation with their PL. 



See [23, Chapter 17] and [20, Chapter 10] for a discussion on the role the 
development environment and standards in CBSE. 



In the absence of the right component, it suffices to only 
develop the missing component and reuse the available ones. 
For example, to get the DLE mechanised in a CBM fashion, 
one plugs together components which correspond to: Var and 
(var x ), App and (app), Srp and (if), Val and (val), as 
well as Let and (let). Out of those components, however, we 
had to develop the Srp one whilst reusing the other four. In 
Section V-A, we take a deeper look into how our mechanisation 
of the (#) rule manages running its two left-most premisses 
in-parallel. Plugging components together usually involves 
preparing some glue code as well. Details of how to develop 
the glue code in this case are discussed in [8]. 



The benefit of using mechanisation goes well beyond sole 
PL implementation. For example, in our initial theory-work, 
we had originally decided for the rightmost assumption of our 
(#) to be 6i M 9 2 : (w e ) _A [v x /_] (where T : x JJ. _ : v x ). It 
turns out that, we did not notice the mistake until our mech- 
anisation revealed it that (v e )~ x [v x / _] produces syntactically 
invalid expressions when v e — Xy.(e' y) for some expression 
e' - thanks to Scala's static type checking. 



Mechanisation is also suitable when it is used in tandem 
with the theoretical development. For instance, our mechani- 
sation made us understand the necessity of the dom(Ti) = 
dom(r 2 ) condition in Definition 5 far before our theory comes 
to that need. Our understanding is that mechanisation helps the 
PL design avoid mistakes that are hard to envision but easier 
to spot in action. The plus point of our CBM technology is 
that it makes rapid PL implementation very feasible. As such, 
it can indeed be a lightweight assistant to PL development. 
See Klein et al. [14] for a comprehensive discussion. 



A. The Executable {jf) Rule 



A winning feature of CBSE (and consequently CBM) is 
the independence nature of components. The benefits of this 
nature for software development are already well explored in 
the literature. (See [23], [20].) The same nature enables us 
here to unveil our mechanisation for the (#) of Definition 6 - 
i.e., HBSharpRuleVal below - without discussing the other 
components. Our follow-up explanation aims to make the tight 
correspondence between HBSharpRuleVal and (jf) clear. 



scaia> printin(g <::> (\[DLEExp] ("zl" , "z2")("zl") <#> "xl")) 

(val) 

{x2 /-> xl y}: \x.x => {x2 /-> xl y}: \x.x 

— (vai) - (var) (vaL) 

G: \zl.\z2.zl ==> G: \zl.\z2.zl G: xl ==> {x2 /-> xl y, xl /-> \x.x): \x.x {x2 /-> xl y, xl /-> \x.x}: \z2.xl ==> {x2 /-> xl y, xl /-> \x.x): \z2.xl 

m 

G: (\zl.\z2.zl) # xl ==> {x2 /-> xl y, xl \-> \x.x}: \z2.xl 



Fig. 2. Mechanised DLE in Action 



object HBSharpRuleVal { 

def apply [ 

Exp <: LazyExp [Exp] , 
Val <: IVal[Exp] with Exp, 
Let <: I Let [Exp] with Exp, 
Srp <: ISrp[Exp] with Exp, 
OS <: OpSem[Exp]{ 

type Conf = HBConf [Exp] 

type Node = HBNode [ Exp ] } 
] (g: Heap [Exp], ex: Srp) = { 
val (e, x) = (ex.e, ex.x) 

val pilf = Future (g <::> e} 
val pi2f = Future {g <: :> x} 

val node = for { 

pil <- pilf 
pi2 <— pi2f 

(tl, ve, t2) = (pil.g2, pil.e2, pi2.g2) 

pi3 <- Future { (tl [><| t2) <::> (ve ~-\ ex.x)} 
(d, v) = (pi3.g2, pi3.e2) 
} yield new HBSrpNode [Exp] (pil, pi2, pi3, 

g, ex, d, v) 

Await . result (node, Inf) 

} 

} 

Lines 3 to 9 manifest the usage protocol of 
HBSharpRuleVal. That is, they specify the wide range 
of syntax and semantics that the component can be used 
with. Lines 3 to 6 state that it can work with any syntax 
mechanisation for laziness that provides the following three 
type constructors - expressed through the respective upper 
bound conditions: Val, Let, and Srp. Similarly, lines 7 
to 9 place restrictions on the operational semantics that 
this rule can be a part of. In short, they state that both the 
semantics and the output derivation trees (like the one in 
Figure 2) need to be heap-based. That is what the prefix HB 
of HBSharpRuleVal indicates. 

The arguments in line 10 are the heap (g for T) and the 
expression (ex for e#a;) this rule is responsible for. Line 
11 extracts the two parts of a strict function application: the 
function (e) and the argument to which the function is applied 
(x). Lines 13 and 14 inform Scala that the evaluations T : e 
and r : x are likely to be examined asynchronous to the rest 
of the computation. 

The real asynchronous computation takes place in the f or- 
comprehension of lines 16 to 25 where pil and pi 2 are run 
in parallel. (Scala's f or-comprehensions are monadic entities 
like the do notation of HASKELL.) Note that pi 3 - which 
represents the rightmost branch of the (jf) - depends on pieces 
of pil and pi 2. Hence, Scala needs to wait for both the latter 
(parallel) evaluations before it can start that of pi 3. Lines 24 
and 25 specify how to build the right derivation out of the 
pieces gathered over the f or-comprehension. Finally, line 27 
instructs Scala to wait until the f or-comprehension is done 



and return the derivation tree specified in lines 24 and 25. 
VI. Related Work 

A. Semantics 

Launchbury [16] was the first to provide an operational 
semantics for lazy evaluation. Nakata and Hasegawa [18] add 
variable hygiene in the style of Sestoft [22] to his work. Our 
garbage-collecting (let) rule leaves no need for such a hygiene 
for us. Hall et al. [9], [2] build on Launchbury's work to get 
a small-step operational semantics for parallel lazy evaluation 
in the presence of selective strictness. Hidalgo-Herrero and 
Ortega-Mallen [II] do the same but for distributed lazy eval- 
uation. This latter work was then followed by Sanchez-Gil 
et al. [21] to provide the first big-step operational semantics 
for the same setting. Our DLE enjoys remarkable simplicity 
in comparison to Sanchez-Gil et al. The other related work 
is that by van Eekelen and de Mol [24], which was the 
first to study selective strictness in a big-step semantics. All 
the above works (except that of ours) suffer from increase 
of heap expressiveness upon evaluation of let-expressions 
(IHEELE). This was first noticed and repaired in [ ] but with 
restrictions on the language expressiveness. These restrictions 
were removed in [6] to form the first big-step semantics for 
lazy evaluation (in the presence of selective strictness) that 
does not suffer from IHEELE. Our present work takes the same 
route to provide a simple big-step semantics for distributed 
lazy evaluation. 

There is a subtle difference between our system and that 
of Sanchez-Gil et al. [ ] that is worth more elaboration: 
Our strict application is similar to their parallel application in 
that, upon encountering an e#x, we both eagerly spawn two 
derivations - one for evaluating e and another for x. However, 
in parallel application, the side effects of the latter evaluation 
are discarded unless x is indeed requested over the former 
evaluation. In strict application, to the contrary, we always 
perform the 9i tx 02, regardless of whether x was needed 
over r : e 4 6i : _ or not. In other words, one can easily 
verify it that in our system affects the heap similar to 
x seq (e x) under traditional selective strictness. That is, 
they both cause the evaluation of the exact same variables. 
Interestingly enough, however, our (#) manages coordination 
in a way that suits task distribution. Whilst that is not possible 
under say (let!) of [24] (for selective strictness). 

We would like here to elaborate on our comment about 
our work being considerably simpler than its sole predecessor: 
Figure 3 illustrates the rules of Sanchez-Gil et al. [21] that 
handle their parallel application. 5 The fact that our single (#) 

5 In fact, they also have four other rules for A-abstractions, variables, 
function applications, and let-expressions. Whilst, for these four rules too 
Sanchez-Gil et al. add complications to those of Launchbury, we only present 
their parallel application rules here. This is because their other four rules are 
not remarkably more complicated than their Launchbury counterparts. 



(Process creation) r = r U T B U {6 h> x#y}, if -,d(x, F) 

r + {mj;,o^ T](x) z, z H> i} + T](nb(x, T')) : 8 ^ o JJ. A : 8 ^ W 

r : 8 h-> x#y i}. A : 8 h-> W 

(Proc. creat. dem.) r' = r U T B U {z ^ E' , 8 i-» x#y}, if d(x, V) A fd(x, F) = z i-> E' hz^Q 

T+{8 B H ] x#y} :z^E' A + {8 x#y} : z ^ W A + {z n- W'} : 8 t-> x#y J| 6 : 8 ^ W 

T + {z ^ E'} : 8 ^ x#y JJ 6 : 8 h> W 

(Communication) if -id(W, A) 

r + {8 B h h) ch}:ch^E 4| A + {8 W ch} : ch h> W 
T+{ch^ E} :8^ ch 4J. sat(A U r](nh(W, A)) : 8 H- r)(W)) 

(Comm. demand) A' = AuA b U{zh E'}, if d(W, A') A fd{W, A') = z4 £' 

r + {6> B ^ l) c/t} : ch h> S J| A + {z ^ £;', 6» c/i} : ch^W 

A + {ch^W,8 ch} : z ^ E' i}.Q + {ch ^ W,8 ^ ch} : z h> W 
6 + {2 ^ r , c/j ^ : f ^ c/i|l A : ^ r' 
r + {eft ^ : 6» ^ c/i ^ A : 8 ^ W" 
where z € Var and o, i, € Chan are fresh names, and rj is a fresh renaming 



Fig. 3. Process Creation and Communication Rules of Sanchez-Gil et al. [21] 

is much simpler than this collection of rules is clear. Most 
of the simplicity in our (#) comes from the fact that its two 
left-most premisses independently (perhaps in par). Whereas in 
Figure 3 four rules are employed for creation of processes and 
communication between them: The rules (Process creation) 
and (Proc. creat. dem.) deal with process creation when that is 
"feasible" and when "dependencies" are detected, respectively. 
Likewise, the rules (Communication) and (Comm. demand) 
handle process communication in the absence and presence of 
"dependencies," respectively. (See [ ] for their definitions of 
dependency and feasibility.) 

B. Mechanisation 

CBM is available under PLanCompS [13], Polyglot [19], 
GLoo [17], and SugarHaskell [ ]. PLanCompS assumes a 
unique semantics for each of its syntax components. The 
other three works of this group target mechanisation through 
syntactic desugaring into a core PL. MontiCore [15] and 
Neverlang 2 [3] are LDFs for DSL mechanisation. Although 
not designed for this particular purpose, the "compositional 
visitors" of MontiCore can be used for CBM. Finally, the focus 
in Neverlang is on component-based compiler generation for 
DSLs where there is no emphasise on a formal semantics. 

VII. Conclusion and Future Work 

In this paper, we present a new operational semantics for 
distributed lazy evaluation that is remarkably simpler than its 
sole predecessor. It also enjoys several interesting properties 
such as validity of Inmb, heap bisimilarity, and a notion of 
determinism (despite its distributed nature). The simplicity in 
our system is not confined to the statement of our semantics 
rules. We showcase the simplicity of proving observational 
equivalences with two intuitive results. Moreover, we explain 
the mechanisation of our system. Finally, we discuss how our 
mutual development of mathematics and mechanisation helped 
us address some unforeseen issues. 



Whilst our (#) indeed models distribution, it is less than 
ideal in comparison to parallel application. (See Section VI.) 
A future work would then be an operational semantics with 
enough simplicity that can model parallel application and 
the study of its properties. That would entail an on-the-fiy 
mechanism for checking looked up variables. We anticipate 
that techniques such as the "busy signal" trick of Hoffmann 
and Shao [ ] would form a good starting point. Another fu- 
ture work can be exploring further observational equivalences 
under our current system. Several threads for future work 
on the mechanisation part are also possible: A crucial one 
can be enriching the PL with new constructs and updating 
the mechanisation for empirical studies on the benefits or 
losses of our flavour of task distribution. Another could be 
mechanisation of the intermediate results we obtained over our 
theoretical development reported in this paper. Finally, trying 
the mechanisation of this work under other CBM frameworks 
is yet another subject for later research. 
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